Document the design in package-info (client-side stats) - #12082
Conversation
|
🎯 Code Coverage (details) 🔗 Commit SHA: f720209 | Docs | Datadog PR Page | Give us feedback! |
There was a problem hiding this comment.
More details
The PR adds only package-level Javadoc; it introduces no runtime path or behavioral change. The documented CSS invariants match the surrounding aggregator, schema, and writer implementation, and deterministic diff/link checks passed; Gradle compile, test, and Javadoc tasks could not run because the sandbox lacks network access to the wrapper distribution and Java 25 toolchain.
🤖 Datadog Autotest · Commit 50cecf3 · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 50cecf306a
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
Add a package-info.java for datadog.trace.common.metrics giving a two-minute mental model of the re-architected client-side-stats (CSS) pipeline: an at-a-glance ASCII flow diagram plus prose on the single-writer threading model, the per-interval aggregate/flush cycle, the bound->sentinel->report-per-cycle cardinality invariant, and the three cardinality-handler families. The per-class javadocs carry the mechanics; this is the top-level shape for a newcomer. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
50cecf3 to
1f7848c
Compare
🟢 Java Benchmark SLOs — All performance SLOs passed
PR vs. master results
Commit: Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion. |
- report() resets entries (retained for reuse; stale expunged over cycles), it does not clear the whole table each interval - OTLP flushes to the OTLP endpoint, not the agent; only msgpack goes to the agent - core string fields use PropertyCardinalityHandler, peer/additional tags use TagCardinalityHandler; primitive key fields are copied directly Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Adopt bric3's suggested intro: drop the CSS acronym and the span-label tuple in favor of a plainer sentence, and state the MetricWriter destinations (msgpack to the Datadog Agent, OTLP to the configured OTLP endpoint) up front. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Replace the single-producer/aggregator sketch with bric3's suggested diagram: show the MPSC inbox as the boundary -- app/producer threads enqueue SpanSnapshots, control threads enqueue SignalItems -- and the aggregator thread as the sole owner handling both, enumerating the Report/Clear/Stop signals. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
What Does This Do
Adds a
package-info.javafordatadog.trace.common.metrics— a two-minute mental model of the re-architected client-side-stats (CSS) pipeline for newcomers to the package.Documentation only; no production code changes.
Motivation
Document the new architecture of client-side stats -- including thread safety, config update model, and publishing cycle
Additional Notes
Contents
MetricWriter(msgpack / OTLP); buckets are deltas.CoreHandlers/PeerTagSchema/AdditionalTagsSchema.The per-class javadocs already carry the mechanics; this is deliberately the top-level shape, not a reference — kept to a short prose read per reviewer feedback that an earlier exhaustive draft was too dense.
Stacking
Stacked on #11402 (the CSS re-architecture this documents). Rebase
--onto masteronce #11402 squash-merges.🤖 Generated with Claude Code